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Abstract 


The  NavLab  is  a  testbed  for  research  in  outdoor  navigation,  image  understanding,  and  the  role  of 
human  interaction  with  intelligent  systems;  it  accommodates  researchers  and  all  computing  onboard.  The 
core  of  the  NavLab  is  the  vehicle  controller,  a  multi-processor  computer  that  controls  all  locomotion, 
actuation  and  physical  sensing;  it  interacts  with  a  computer  host  and  human  operator  to  implement 
varying  degrees  of  autonomy.  The  chassis  is  a  modified  van  with  a  computer-controllable,  hydraulic 
drivetrain.  The  NavLab  supports  a  choice  of  sensing  to  accommodate  many  types  of  navigation  research. 
This  technical  report  details  the  control  computing  and  physical  configuration  of  the  NavLab  vehicle. 


1.  Introduction 

The  NavLab  is  a  testbed  for  research  in  outdoor  navigation,  ;mage  understanding,  and  the  role  of  human 
interaction  with  intelligent  systems.  A  mobile  navigation  habitat,  it  accommodates  researchers  and 
significant  onboard  computing.  Applications  for  field  navigation  vehicles  include  mapping  of  hazardous 
waste  sites,  off-road  haulage,  material  handling  at  construction  worksites,  and  exploration  of  planetary 
surfaces. 

The  NavLab  is  a  roadworthy  truck  modified  so  that  humans  or  computers  can  control  as  occasion 
demands.  Because  it  is  self-contained,  it  is  not  subject  to  telemetry  bottlenecks,  communication  faults  or 
dependence  on  stationary  infrastructure,  and  can  travel  to  confront  navigation  problems  of  interest  at  any 
site. 

The  core  of  the  NavLab  is  the  vehicle  controller.  In  autonomous  mode,  this  multi-processor  computer 
controls  all  locomotion,  actuation  and  physical  sensing.  It  interacts  with  a  computer  host  and  human 
operator  to  implement  varying  degrees  of  autonomy.  The  NavLab  controller  queues  and  executes  Virtual 
Vehicle  commands  originating  from  a  computer  or  human  host.  This  command  set  provides  high-level 
motion  and  control  primitives  that  mask  the  physical  details  of  the  vehicle,  and  is  extensible  for  control  of 
other  mobile  systems. 

The  NavLab  configuration  consists  of  a  chassis,  drivetrain  and  shell.  The  chassis  is  a  modified,  cut-away 
van  with  a  computer-controllable,  hydraulic  drivetrain.  Driver's  controls  allow  a  human  monitor  to  override 
automatic  control  for  overland  travel,  setup  and  recovery  from  experimental  errors.  The  shell  houses  all 
onboard  equipment  including  computers,  controllers,  telemetry,  and  internal  sensors.  In  addition,  it 
provides  a  working  area  for  operators,  allowing  research  within  the  confines  of  the  vehicle.  Equipment 
racks,  monitors,  lighting,  air-conditioning,  seating  and  desk  space  create  a  mobile  environment  for 
research. 

Humans  can  monitor  and  supervise  the  NavLab  from  the  operator’s  console  for  setup,  error  recovery  and 
tuning.  Interface  modes  include  Virtual  Vehicle  instructions,  joystick  motion  control,  and  direct  servo 
motion  commands.  The  console  also  incorporates  several  displays  to  show  the  current  states  of  both  the 
vehicle  and  control  computer. 

The  NavLab  supports  a  choice  of  sensing  to  accommodate  many  types  of  navigation  research.  Video 
cameras  provide  color  and  intensity  images  for  scene  interpretation.  NavLab  vision  experiments  use  a 
single  camera  to  analyze  road  edges  through  intensity,  texture,  and  color  segmentation.  A  scanning 
rangefinder  sweeps  the  surroundings  with  a  distance-measuring  laser  that  provides  useful  three- 
dimensional  information  about  the  geometry  and  reflectivity  of  the  environment.  Laser  experiments 
navigate  through  geometric  features  like  trees  and  buildings.  Taken  together,  data  of  color,  intensity, 
range  and  reflectance  provide  a  rich  basis  for  building  natural  scene  descriptions.  Sensor  information 
from  several  sources  can  be  fused  to  achieve  more  robust  perception.  A  blackboard  architecture 
integrates  the  distributed  processes  that  sense,  map,  plan  and  drive. 

The  NavLab  represents  continuing  evolution  in  the  design  of  navigation  vehicles.  Fully  self-contained,  it 
is  a  milestone  in  mobile  robotics. 

This  technical  report  details  the  control  computing  and  physical  configuration  of  the  NavLab  vehicle. 
Information  on  other  aspects  of  the  NavLab,  including  perception,  modelling,  planning  and  blackboard 


2.  Controller 

The  NavLab  controller  parses  and  implements  a  Virtual  Vehicle  instruction  set.  The  controller  is 
implemented  as  a  loosely  coupled  parallel  processor.  Commands  are  received  via  a  serial  link  from  Host 
computers  or  an  onboard  console.  Five  axes  of  motion  are  controlled:  drive,  steering,  pan  and  tilt  motions 
for  the  cameras,  and  a  pan  motion  for  a  laser  ranging  device.  Status  of  devices  onboard  is  monitored  by 
a  sensor  subsystem  that  constantly  polls  processors  dedicated  to  groups  of  sensors  via  a  high-speed 
serial  bus.  Status  information  is  displayed  on  the  console  inside  the  vehicle  and  is  available  to  the  Host 
computer  via  queries. 

2.1  System  Architecture 

The  control  computing  for  the  NavLab  is  based  on  the  hierarchy  shown  in  Figure  2-1,  a  system 
architecture  for  robot  modeling  and  planning  associated  with  autonomous  task  execution  in  unstructured 
and  dynamic  environments.  The  NavLab  controller  is  tantamount  to  the  lowest  level  of  the  architecture. 
The  need  for  an  interface  protocol  between  the  control  computing  and  the  higher  level  computing  forges 
the  virtual  system,  which  allows  the  low-level  control  computing  to  mask  the  physical  implementation 
details  from  the  higher  level  computing.  This  is  accomplished  through  command  primitives  that  define  the 
interface.  Using  the  virtual  system,  many  of  the  high-level  modeling  and  planning  functions  can  port 
across  a  number  of  different  physical  systems  that  can  be  controlled  with  the  same  command  primitives. 
Only  the  lowest  level  control  computing  must  deal  with  the  physical  differences  of  the  system. 

Complex  systems  usually  defy  any  attempts  at  mathematical  modeling  techniques,  which  makes  control 
parameters  impossible  to  even  estimate.  A  set  of  pseudo  constants,  tunable  from  an  operator's  console, 
adjust  the  parameters  and  gains.  The  NavLab  maintains  these  constants  in  file  structures  that  remain  on 
disk  for  power-up  initialization.  The  system  always  starts  up  with  default  values  established  from  the  most 
recent  tuning  of  the  system. 

The  control  computing  accepts  commands  from  a  host  or  human  operator  who  can  intervene  at  various 
levels  of  control  to  insure  safe  operation  during  experiments.  The  assumption  during  development  is  that 
the  higher  levels  of  computing  will  not  succeed  in  all  situations.  The  control  computing  thus  provides  a 
graceful  transition  between  computer  and  human  control  when  failures  occur.  The  hooks  for  human 
inputs  are  also  useful  for  setup  and  recovery  during  experiments. 

The  sensors  monitored  by  control  computing  reflect  the  state  and  ability  of  the  system  to  respond  to 
commands  issued  by  the  cognitive  planning  layers.  The  values  of  the  observed  parameters  have  fixed 
maximum  limits  that  are  characterized  by  the  physical  system.  These  limits,  however,  are  not  static  and 
can  move  inward  during  certain  operating  conditions.  Physical  parameters  such  as  heat  and  pressure  can 
diminish  NavLab's  mechanical  ability  to  respond  to  commands.  The  parameter  limits  are  dynamically 
adjustable  by  the  controller  to  protect  the  NavLab.  When  controlling  with  a  powerful  physical  plant  like  the 
NavLab,  erroneous  plans  and  commands  have  significant  impact.  The  control  computer  should  never 
execute  commands  blindly,  so  mechanisms  are  needed  for  validating  and  rejecting  commands,  with 
advisories  communicated  to  the  source  of  commands. 

Control  computing,  the  lowest  of  the  three  levels  within  the  autonomous  mobile  system  architecture, 
interacts  with  the  physical  system.  The  design  criteria  set  forth  for  the  NavLab  low-level  controller  include 
an  open-ended  architecture,  a  virtual  system  interface  and  multiple  command  streams. 
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Planning:  What  to  do? 


2.2  Virtual  Vehicle 

A  Virtual  Vehicle  is  a  man-machine  interface  that  accepts  conceptual  commands  and  provides  a  clean 
separation  between  the  navigation  host  and  vehicle  control.  This  interface  masks  implementation  details 
of  the  physical  vehicle,  facilitating  adaptability  to  future  navigation  testbeds. 

The  Host  (the  computing  engine  that  does  planning)  communicates  with  the  Virtual  Vehicle  via  ASCII  data 
transmitted  over  a  serial  line.  The  communication  falls  into  three  categories: 

•  Commands  issued  by  the  Host 

•  Queries  by  the  Host  about  the  status  of  devices 

•  Reports  initiated  by  the  Virtual  Vehicle  on  completion  of  commands  and  in  case  of 
emergency. 

In  the  current  implementation,  the  vehicle  is  directed  along  circular  arcs  because  arcs  are  quickly 
computed  and  absolute  position  is  not  critical  (the  arcs  are  being  upgraded  to  clothoids).  Because  it  is 
not  possible  for  a  vehicle  to  switch  between  an  arc  of  one  curvature  and  another  instantly,  path  transitions 
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are  inexact.  Errors  are  compensated  for  by  dynamically  planning  arcs  to  reach  subgoal  points  along  the 
path. 

To  facilitate  synchronization,  all  drive  and  steering  commands  are  initiated  at  the  transitions  between 
arcs.  The  capability  is  provided  to  make  changes  to  vehicle  motion  (e.g.,  curvature  of  the  arc,  vehicle 
velocity)  on  the  fly.  Arcs  (specified  as  [arclength,  radius  of  curvature])  can  be  queued  for  sequential 
implementation. 

The  Virtual  Vehicle  and  Host  interact  as  follows: 

•  The  Host  issues  a  new  arc  command  before  the  arc  in  execution  is  completed. 

•  If  an  immediate  condition  is  specified,  the  old  arc  is  discarded  and  the  new  arc  is  accepted 
immediately.  Otherwise,  the  new  arc  is  initiated  at  the  end  of  the  arc  being  executed. 

•  When  a  new  arc  is  initiated,  vehicle  position  is  reported  to  the  Host  for  use  in  calculating 
future  path  plans. 

•  The  Host  incorporates  the  reported  position  in  planning  the  next  arc,  thereby  compensating 
for  deviations  from  the  desired  path. 

The  Virtual  Vehicle  instruction  set  and  details  of  interfacing  can  be  found  in  Appendix  IV. 

2.3  Controller  Architecture 

The  NavLab  controller  is  a  powerful  and  flexible  multi-processor  system.  A  functional  block  diagram  of 
the  controller  is  shown  in  Figure  2-2.  A  Pilot  module,  responsible  for  management  and  operation  of  the 
key  peripherals  and  I/O  devices  in  the  system,  maintains  direct  control  of  all  physical  action  and  motion. 
The  Pilot  is  also  responsible  for  system  startup  and  synchronization  and  acts  as  the  hub  in  a  star 
configuration  for  inter-processor  communication.  A  Command  Preprocessor  manages  I/O  between  the 
controller  and  devices  that  communicate  with  it.  The  Sensor  Manager  controls  a  network  of  8-bit  micro¬ 
controllers  distributed  throughout  the  vehicle  to  provide  points  of  intelligent  analog  and  digital  I/O. 
Accommodations  are  made  for  an  Advisor  to  set  limits  on  physical  motion  parameters  based  on  the 
perceived  condition  of  the  mechanical  systems  of  the  vehicle.  The  Advisor  incorporates  a  bump  detection 
subsystem  that  signals  the  Pilot  if  immediate  action  is  necessary. 

Each  module  in  the  system  contains  its  own  operating  environment  for  independent/parallel  operation. 
The  operating  environments  are  subsets  of  those  used  for  system  development.  Code  for  each  module  is 
down-loadable  to  permit  easy  modification  to  the  system. 

2.3.1  Hardware 


•. 


The  NavLab  controller  is  designed  as  a  two-tiered  multi-processor  system.  The  first  tier  is  responsible  for 
the  primary  computing,  control  I/O  and  motion  control.  It  is  comprised  of  4  Intel  28612  processor  boards 
residing  in  a  common  Multibus  backplane.  The  second  tier  performs  remote  data  acquisition  and  control 
of  devices  located  around  the  vehicle  using  a  serial  network  of  8-bit  micro-controllers.  The  Sensor 
Management  System  in  the  first  tier  is  the  interface  between  the  two  tiers. 


* 


2.3.1 .1  Primary  Computing 

Processors  in  the  first  tier  take  advantage  of  the  multiple  bus  structure  of  the  system  to  increase 
processing  throughput.  Each  processor  contains  a  local  bus  with  enough  memory  resources  to  support 
its  own  execution  environment.  Processors  have  bus  master  capabilities  to  access  and  control  I/O 
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Figure  2-2:  Architecture  of  Controller 

boards  and  shared  memory  spaces.  Critical  memory  and  I/O  locations  are  controlled  using  a  semaphore 
system  while  bus  contention  is  arbitrated  in  hardware.  Interrupt  lines  in  the  Multibus  backplane  tie  the 
processors  together  for  inter-processor  communications. 

Each  processor  is  identically  configured  with  256  K  local  ROM,  512  K  local  RAM,  and  a  256  K  window  to 
the  Multibus.  The  ROMs  on  the  I/O  processors  only  contain  operating  system  software  and  a  download 
facility  to  allow  loading  of  applications.  The  multiple  bus  structure  permits  a  total  system  memory  of  2.5 
MB  even  though  only  1  MB  is  addressable  from  each  processor. 

The  controller  also  contains  intelligent  slave  boards  for  I/O  expansion  and  servo  motor  control.  These 
boards  may  be  accessed  by  any  bus  master.  Often,  access  is  restricted  to  a  specific  processor  to  avoid 
contention  problems. 
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Figure  2-3:  Hardware  Configuration 


2.3.1 .2  Secondary  Computing 

The  second  computing  tier  physically  distributes  sensing  and  control  of  devices  around  the  vehicle  by 
using  nodes  that  consist  of  8-bit  microcontrollers  communicating  over  a  high-speed  serial  bus  using  a 
message  protocol  called  Bitbus.  The  network  is  controlled  by  a  Master  node  that  either  continually  polls 
other  nodes  to  read  analog  and  digital  inputs  or  continuously  commands  them  with  reference  values.  The 
communication  overhead  makes  Bitbus  suitable  to  tasks  that  require  high-level  control  and  slow  data 
acquisition.  The  serial  bus  network  is  extensible  to  support  up  to  250  nodes.  Further  implementation 
details  of  Bitbus  can  be  found  in  Section  2.3.5. 1. 

2.3.2  System  Software 

System  software  for  the  controller  is  based  on  the  iRMX  86  real-time  operating  system.  iRMX  is 
configurable  to  customize  operating  environments  for  each  processor  in  the  system.  These  operating 
environments  are  resident  in  ROM  local  to  each  board  and  are  booted  from  reset.  iRMX  86  provides 
objects  to  support  an  event-driven,  multi-tasking  environment. 

A  facility  to  down-load  object  r~de  was  developed  for  building  and  testing  multiprocessor  systems.  A 
single  processor  accesses  the  mass  storage  device  containing  object  code  files  for  downloading.  This 
processor,  like  a  system  server,  loads  object  code  into  shared  memory  and  signals  the  appropriate  target 
board  when  a  valid  record  is  available.  The  other  processors  contain  consumer  jobs  to  copy  records  from 
shared  memory  to  their  local  memory.  On  signal  from  the  server  processor,  a  consumer  job  releases  the 
server  CPU  to  allow  the  local  Operating  System  to  start  the  jobs  from  the  newly  loaded  code.  Once  the 
application  software  is  running,  the  consumer  load  job  lies  idle  and  waits  for  a  signal  from  the  server 
processor  to  reset  and  begin  the  load  sequence  again.  This  flexible  load  facility  is  a  valuable  tool  for 
building  and  testing  multiprocessor  systems. 


2.3.2. 1  Interprocessor  Communication 

Processors  communicate  using  shared  memory  in  two  different  ways.  Common  variables  are  accessed 
by  multiple  processors  to  share  state  information  (scratch  pad  communication).  Messages  can  also  be 
written  to  specific  memory  locations  on  other  processor  boards  and  the  receiving  board  is  signaled  by  an 
interrupt.  This  method  is  often  used  by  one  board  to  direct  processing  on  another  board. 

Scratch  Pad  Communication 

This  method  is  a  simple  solution  to  sharing  a  large  amount  of  data  between  modules.  Processes  that 
acquire  data  (status  of  devices,  vehicle  orientation,  speed,  etc.)  post  this  information  to  the  scratch  pad 
area  instead  of  sending  the  data  to  all  modules  that  need  them.  Most  shared  variables  are  independent 
of  each  other;  hence  contention  problems  are  limited  to  access  of  the  individual  memory  locations  to  read 
or  write.  Dependent  variables  (ones  that  must  be  accessed  as  a  group)  require  a  software  semaphore  to 
provide  mutual  exclusion.  An  indivisible  test  and  set  instruction  provided  by  PL/M-86  was  used  to  create 
the  semaphore  system. 

Module  for  Interprocessor  Communications 

The  Module  for  Interprocessor  Communication  (MIC)  was  developed  to  support  flexible  pipelined 
communications  between  tasks  running  on  separate  processor  boards.  MIC  provides  the  applications 
programmer  with  a  simple  set  of  procedure  calls  from  which  a  task  can  queue  messages  containing  a 
board  and  task  destination.  MIC  handles  the  transfer  of  these  messages  between  boards. 

MIC  is  implemented  as  a  star  architecture.  Alt  messages  are  sent  through  a  central  node  to  limit  the 
number  of  required  interrupt  lines.  This  scheme  is  well  suited  to  the  NavLab  controller  because  most 
interprocessor  communications  are  to  a  central  node  (the  Pilot). 

MIC  was  built  using  tools  provided  by  iRMX  including  inter-task  communication,  dynamic  memory 
allocation,  and  FIFO  queues.  MIC  runs  as  an  interrupt-driven  task.  It  responds  to  signal  interrupts  to 
determine  the  desf  nation  of  a  received  message  and  then  sends  it  to  the  appropriate  task.  iRMX  system 
calls  permit  asynchronous  message  transfers  between  tasks. 

MIC  was  designed  to  be  compact  (5  K),  fast,  and  capable.  MIC  is  able  to  dynamically  allocate  message 
segments  to  meet  the  load  of  interprocessor  communication  traffic  that  varies  from  processor  to 
processor.  This  prevents  wasting  memory  and  time  required  by  the  system  programmer  to  tune  buffer 
sizes  for  individual  boards.  When  application  code  is  modified  to  change  message  traffic,  MIC  can  adjust 
to  use  only  the  necessary  memory  resources. 

2.3.3  Command  Preprocessor 

The  Command  Preprocessor  front-ends  I/O  originating  from  two  sources;  the  driving  Host  computer 
(Host)  and  the  operator’s  console  (Console).  At  the  lowest  level,  it  drives  the  physical  data  links 
supporting  these  command  streams.  In  the  NavLab  controller,  RS232C  serial  channels  are  controlled.  At 
the  next  level,  it  validates  data  integrity  of  Host-originated  Virtual  Vehicle  Interface  (Wl)  command 
packets  by  checking  format  correctness,  parameter  count,  and  packet  size.  At  the  highest  level  it  checks 
parameter  values  against  established  limits.  The  Command  Preprocessor  has  the  ability  to  reject 
commands  exceeding  the  current  operating  limits,  but  the  Pilot  has  final  authority  on  command 
acceptance.  Query  commands  issued  by  the  Host  are  handled  directly  by  the  Command  Preprocessor 
without  Pilot  involvement. 


The  Command  Preprocessor  communicates  primarily  with  the  Pilot  module.  The  other  modules  are 
indirectly  accessed  through  value  lookups  in  the  Scratch  Pad.  All  commands  involving  action,  such  as 
motion  commands  or  control  commands  to  a  device  managed  by  the  Bitbus  Sensor/Control  Network,  are 
first  sent  through  the  Pilot  to  update  its  knowledge  of  the  vehicle  state  affected  by  the  controller. 

The  Command  Preprocessor  contains  two  separate  subprocesses  to  service  the  Host  and  Console 
concurrently.  The  Host  Interface  is  responsible  for  maintaining  communications  between  the  controller 
and  the  Host.  The  Console  Interface  interprets  commands  from  the  operator  console  keyboard.  The 
Console  is  given  priority  over  the  Host  so  that  it  is  possible  for  the  operator  to  override  Host  commands. 
Commands  are  received  as  ASCII  packets.  The  Host  sends  only  numeric  data;  each  command  is  given 
an  opcode.  The  Console  allows  the  operator  to  enter  commands  as  simple  mnemonics. 

Communication  errors  are  trapped  by  syntactic  data  validation.  The  Command  Preprocessor  takes  two 
different  actions  based  on  the  type  of  command  it  receives.  For  motion  commands,  the  arguments  are 
validated  based  on  the  allowable  ranges  of  vehicle  motions  posted  in  shared  memory  by  the  Advisor.  If 
all  the  arguments  are  acceptable,  the  command  is  passed  on  to  the  Pilot.  An  acknowledge  message  is 
then  sent,  signaling  that  the  command  was  accepted  and  will  be  executed.  If  for  any  reason  the 
command  is  found  to  be  invalid,  a  disacknowledge  message  along  with  an  explanation  for  rejection  is 
sent  to  the  command  initiator. 

The  Command  Preprocessor  processes  query  commands  (e.g.,  heading,  position).  The  requests  are 
satisfied  by  accessing  the  shared  memory  region  where  the  information  is  updated  constantly.  This 
method  makes  it  unnecessary  to  interrupt  other  processes.  The  data  is  formatted  and  shipped  to  the 
requestor. 

The  Command  Preprocessor  also  maintains  the  display  on  the  operator  console  onboard  the  NavLab. 
The  screen  is  divided  into  three  parts: 

1 .  Display  --  A  window  displays  vehicle  data.  The  operator  can  select  between  5  different 
displays: 

•  Sensor  data  shown  in  graphical  form  (vertical  bars). 

•  Sensor  data  shown  in  alphanumeric  form. 

•  Status  of  switches  controlled  by  the  controller  shown  in  alphanumeric  form. 

•  Command  packets  between  controller  and  the  Host. 

•  A  help  screen  that  explains  how  the  operator  can  control  the  vehicle  by  using  the 
Virtual  Vehicle  instruction  set. 

2.  Command  line  --  Allows  the  operator  to: 

•  Enter  Virtual  Vehicle  commands. 

•  Enter  software  joystick  commands. 

•  Turn  on/off  switches  controlled  by  the  Bitbus  network. 

3.  Information  area  --  A  window  is  reserved  for  special  messages  that  may  be  sent  by  any 
process  in  the  controller. 

2.3.4  Pilot 

The  Pilot’s  main  function  is  controlling  or  initiating  all  physical  action  and  motion  control.  The  Pilot  also 
plays  the  central  role  in  inter-processor  communications  by  acting  as  the  hub  in  a  star  configuration.  All 
commands  altering  the  state  of  the  vehicle  are  filtered  through  the  Pilot,  eliminating  contention  and  state 
ambiguity  problems  potential  to  systems  altered  by  multiple  independent  processes.  For  the  generalized 


case,  the  Pilot  module  would  occupy  several  processor  boards  and  handle  manipulation  as  well  as 
locomotor  control. 

The  Pilot  is  composed  of  a  hierarchy  of  concurrent  processes  (tasks),  each  of  which  is  dedicated  to 
maintaining  a  specific  subset  of  state  variables  and  initiating  all  actions  affecting  those  variables.  At  the 
lowest  level,  each  axis  of  motion  has  an  individual  driver  process  associated  with  it  that  formats  motor- 
controller  specific  command  strings,  performs  I/O  exchanges  with  the  motor-controller  board,  and 
maintains  the  current  values  of  ail  pertinent  variables  for  that  axis  in  local  memory.  The  axis  drivers  at 
this  level  have  no  notion  of  the  physical  configuration  of  the  overall  system.  Coordination  of  motions  is 
handled  by  higher-level  processes. 

Action  requests  can  be  submitted  to  the  Pilot  by  the  Command  Preprocessor  at  any  time.  On  receipt  of 
such  a  request,  the  Pilot  returns  an  acknowledge/disacknowledge  message  to  the  Command 
Preprocessor  indicating  whether  it  can  execute  the  command.  If  the  received  command  can  be  executed, 
it  is  decoded  and  forwarded  to  the  appropriate  subprocess  for  handling.  Depending  on  the  type  of  action 
requested,  this  process  may  then 

•  direct  motions  (via  the  appropriate  axis  drivers) 

•  read  or  set  parallel  I/O  lines  (for  example,  to  select  a  different  transmission  gear) 

•  update  the  values  of  some  state  variables. 

Because  individual  processes  each  have  a  specific  run-time  priority,  critical  commands  (e.g.,  "STOP") 
always  obtain  control  of  the  CPU,  even  if  a  lower-priority  command  is  still  in  progress.  Also,  because  task 
scheduling  is  event-driven  rather  than  time-shared,  high-priority  processes  always  run  uninterrupted,  i.e., 
in  constant  time. 

A  special  set  of  tasks  within  the  Pilot  maintains  and  processes  a  queue  of  arcs  specifying  a  path  for  the 
vehicle.  These  arcs  are  executed  continuously  and  a  position  report  is  issued  to  the  Command 
Preprocessor  on  completion  of  each  arc.  Velocity  and  acceleration  parameters  can  be  updated  at  any 
time  during  execution  of  an  arc;  in  addition,  one  value  for  each  of  these  variables  may  be  queued  to  go 
into  effect  with  the  beginning  of  the  next  arc  execution. 

The  Pilot  has  the  final  responsibility  for  command  acceptance  or  rejection,  command  queue  management, 
and  implementing  established  equations  to  achieve  requested  arc  trajectories.  Implementation  details  of 
the  vehicle  are  masked  by  the  Pilot. 

The  NavLab  incorporates  braking  as  well  as  forward  and  reverse  propulsion  in  a  single,  bi-directional 
hydrostatic  drive.  For  the  generalized  vehicle  case,  the  Pilot  would  coordinate  brake/throttle  control  to 
achieve  velocity  and  position  objectives.  At  the  servo  level,  motion  is  controlled  by  motion  control  boards 
commanded  by  the  Pilot.  Emergency  stop  conditions  are  signaled  to  the  Pilot  by  a  critical  interrupt  line 
controlled  by  a  planned  Health  Preservation  module  with  bump  detection  facilities.  On  assertion  of  this 
line,  the  Pilot  is  responsible  for  graceful  shutdown,  leaving  the  vehicle  ready  for  recovery  actions  issued 
from  the  operator's  console.  Because  only  the  Pilot  controls  the  motion,  it  is  always  aware  of  the  current 
motion  state. 

Finally,  a  few  background  processes  perform  such  functions  as  maintaining  the  system  clock  and 
calculating  position  coordinates  based  on  sensor  measurements. 


2.3.5  Sensor/Device  Management  System 

Apart  from  the  five  main  axes  of  motion,  there  are  numerous  sensors  that  must  be  monitored  and  devices 
that  must  be  activated.  The  Sensor/Device  Management  System  manages  two  classes  of  sensors.  The 
first  class  is  characterized  by  sensors  and  devices  that  need  not  be  monitored/controlled  frequently.  For 
example,  a  sensor  might  be  dedicated  to  monitoring  hydraulic  fluid  temperature;  while  this  information  is 
important,  it  is  not  essential  that  it  be  updated  more  frequently  than  once  in  several  seconds.  Another 
class  of  sensors  is  that  group  of  devices  that  must  be  monitored  frequently.  An  example  is  a  process  that 
must  analyze  data  from  inertial  devices  and  post  these  results  in  shared  memory  several  times  a  second. 

2.3.5.1  Bltbus  System 

The  Bitbus  System  is  a  highly  flexible  and  expandable  data  acquisition  and  control  system.  By  taking 
advantage  of  the  Bitbus  distributed  control  architecture,  the  Distributed  System  supports  analog  status 
sensors  and  digital  I/O  channels  using  microcontrollers  distributed  on  a  serial  network.  Nodes  on  this 
network  transfer  data  to  the  Bitbus  Server  module  using  the  Bitbus  message  passing  protocol.  The  Bitbus 
nodes  are  programmable  to  meet  a  wide  range  of  sensor  and  control  configurations.  Data  returned  to  the 
Bitbus  server  are  conditioned  and  scaled  at  the  Bitbus  node,  reducing  computational  requirements  of  the 
Bitbus  server. 

The  primary  responsibility  of  the  Bitbus  server  is  to  acquire  and  move  sensor  data  to  shared  memory 
locations  recognized  by  other  modules  in  the  controller.  When  the  Pilot  sends  an  action  command 
request,  the  server  must  format  messages  to  control  any  devices  supported  by  a  Bitbus  node.  In  support 
of  these  functions,  the  server  must  also  handle  node  initialization,  self-monitoring,  and  fault  recovery  for 
the  Bitbus  network.  The  chief  advantage  of  using  a  Bitbus  network  is  the  modular  expandability  and 
flexibility  that  is  inherent  to  the  Bitbus  architecture.  Complex  inter-processor  message  passing  facilities 
are  included  in  the  architecture,  relieving  the  programmer  of  much  responsibility. 

In  simple  systems  with  limited  I/O  points,  the  Distributed  System  could  be  replaced  with  a  single  board 
computer  equipped  with  the  appropriate  I/O  expansion  modules.  An  effort  should  be  made  to  keep  I/O 
operations  local  to  the  processor  to  avoid  consuming  bus  bandwidth.  With  either  implementation 
scenario,  the  update  rates  of  shared  variables  should  be  adjustable  to  control  the  bus  access  frequency 
of  the  Distributed  System  for  tuning  purposes. 

The  Bitbus  network  provides  a  distributed  control  structure  to  service  the  first  class  of  sensors.  A  list  of 
sensors  and  devices  on  this  network  can  be  found  in  Section  2.5.2. 

The  Bitbus  network  is  based  on  a  master  (Bitbus  server)  and  slave  (Bitbus  nodes)  concept  (Figure  2-4). 
Nodes  provide  the  connection  between  the  sensors/devices  and  the  central  Bitbus  Server.  Because  each 
node  operates  independently,  fast  data  acquisition  can  be  achieved  by  distributing  the  work  load  among 
many  nodes.  Nodes  can  also  be  programmed  to  perform  control  tasks  by  reacting  immediately  to  critical 
conditions  as  they  arise. 

The  Bitbus  Server,  one  process  on  the  Sensor  Management  Module,  initializes  the  network  and  monitors 
status.  Because  the  nodes  cannot  initiate  communications,  the  Server  must  continuously  poll  each  node 
for  output  data.  When  the  Server  receives  a  message  from  a  node,  it  posts  the  relevant  information  in 
shared  memory  for  reference  by  other  processes.  When  some  high-level  process  needs  to  control  a 
Bitbus  node,  a  message  is  sent  to  the  Server.  This  message  is  then  broadcast  on  the  network  where  it  is 


Figure  2-4:  Bitbus  Server 
trapped  and  processed  by  the  addressed  node. 

2.3.52  Fast  Sensor  Monitoring 

The  Sensor  Management  system  also  maintains  processes  to  monitor  those  devices  that  must  be 
serviced  at  a  high  frequency.  At  present,  the  only  such  device  envisioned  is  an  inertial  Navigation 
System  anticipated  to  report  position  and  orientation  data  about  10  times/sec.  The  incoming  data  is 
parsed  and  posted  in  shared  memory.  Other  devices  that  need  to  be  monitored  constantly  can  be  added 
to  the  controller  simply  by  allocating  a  process  to  them.  This  method  is  preferable  to  the  Bitbus  method 
when  data  must  be  accessed  frequently  and  must  be  made  available  to  the  entire  system  quickly. 

2.4  Motion  Control 

Of  the  5  axes  of  motion,  only  drive  and  steering  can  be  controlled  both  manually  and  automatically.  The 
other  three  motions  of  pan  and  tilt  are  only  used  in  automatic  operation.  Figure  2-5  (a)  shows  the 
configuration  during  manual  operation.  All  axes  of  motion  on  the  NavLab  are  physically  controlled  by 
Galil  DMC-200  series  motor  controllers.  These  controllers  were  chosen  for: 

•  Multibus  compatibility 


•  multiple  modes  of  control  (position,  velocity,  torque) 


Onvertetl 

Encoder 
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•  coordinated  motion  of  two  or  more  axes  (DMC-200  only) 

•  programmable  acceleration  and  slew  rates 

•  status,  position,  and  error  reporting. 

A  digital  phase  lead  control  law  with  adjustable  gain,  pole  and  zero  provides  a  stable  closed-loop  system 
for  a  wide  range  of  plant  dynamics.  The  motor  controllers  communicate  with  the  Pilot  subsystem  through 
Multibus  I/O  ports  for  data  as  well  as  handshake  exchange. 

Single  axis  Galil  DMC-201  controllers  are  used  for  steering,  drive,  and  laser-ranging  pan  motions,  while  a 
DMC-200  two-axis  unit  is  used  for  the  camera  pan  and  tilt  (Figure  2-5  [b]).  Each  controller  is  software- 
calibrated  at  power-up  to  match  the  dynamics  of  the  controlled  axis.  Thus,  motor  controller  boards  can  be 
interchanged  simply  by  selection  of  appropriate  I/O  addresses  via  jumpers. 

2.4.1  Dash  Panel  Control 

The  vehicle  operates  manually  to  simplify  transport  to  and  from  test  sites.  Manual  operation  doesn't 
require  any  computing  or  generator  power.  The  electronic  components  active  during  manual  operation 
are  powered  by  the  NavLab’s  1 2  V  system. 


Figure  2*6:  Dash  Panel  Layout 

A  human  interface  is  incorporated  for  safe  and  easy  use  by  drivers  of  standard  automobiles.  Figure  2-6 
shows  illuminated  pushbutton  controls  mounted  within  reach  of  the  driver. 

•  High,  Neutral,  &  Low:  allow  the  operator  to  choose  gears.  Because  switching  directly  from 
one  gear  to  another  produces  an  unsafe  lurching  of  the  vehicle,  a  hardware  logic  function 
allows  switching  only  by  first  selecting  Neutral. 

•  Forward,  Reverse:  select  the  direction  in  which  the  vehicle  moves. 

•  Auto/Manual:  a  pull-push  switch  that  switches  between  manual  and  automatic  control. 

•  Emergency  Stop:  disables  autonomous  locomotion  and  brings  the  vehicle  to  a  rapid, 
controlled  stop.  Servo-lock  of  steering  is  disabled;  steering  is  returned  to  manual  control. 

•  Brake  Pedal:  as  in  commercial  cruise  control  systems,  a  light  touch  of  the  brake  pedal  brings 


the  vehicle  back  under  manual  control. 

•  Speed  Control  Pedal:  activates  a  20K  ohm  potentiometer  to  produce  a  voltage  proportional 
to  the  angle  of  deflection  of  the  pedal. 

•  Throttle  Control:  this  dial  sets  the  vehicle  engine  RPM  as  detailed  in  Section  4.2.1 .1 . 

•  HE:  this  switch  turns  on/off  the  heat  exchanger  fan  for  the  hydraulic  system. 

•  HP,  LP:  These  lamps  are  lit  when  the  dirty  oil  filters  in  the  high  and  low  pressure  hydraulic 
systems  indicate  an  alarm. 

By  default,  when  the  vehicle  is  powered  up,  it  is  put  into  manual  mode,  neutral  gear,  and  forward 
direction,  it  is  necessary  to  provide  the  ability  to  override  the  autonomous  mode  in  a  fast  but  controlled 
manner  if  an  emergency  develops.  To  ensure  reliable  operation,  manual  override  is  a  hardwired 
electronic  circuit  with  sealed  electromagnetic  relays  instead  of  sequential  logic  gates.  This  design  proved 
to  be  immune  to  the  noise  and  power  fluctuations  common  to  automotive  electrical  systems.  Because 
this  circuitry  is  essential  to  vehicle  locomotion,  it  is  powered  by  the  vehicle  12  V  system  rather  than  the 
generator. 

An  electronic  ramp/hold  circuit  in  series  with  the  foot  pedal  provides  adjustable  limits  on  acceleration  and 
deceleration  and  ensures  that  abrupt  movements  of  the  foot  pedal  do  not  cause  the  vehicle  to  lurch.  This 
feature  was  included  both  for  safety  and  ease  of  driving.  A  second  ramp/hold  unit  ensures  a  smooth 
deceleration  in  case  of  an  emergency  stop. 

2.4.2  Steering  Control 

The  steering  control  system  consists  of  a  computer-controlled  DC  servo  motor  linked  to  the  steering 
column  by  a  toothed  belt.  A  single  axis  motor  controller  (DMC-201)  uses  feedback  from  an  optical 
1200-line  incremental  encoder  mounted  directly  on  the  motor  shaft  to  maintain  tight  position  control  over 
the  steering  wheel.  A  servo-amplifier  converts  the  +/-  10V  control  signal  from  the  motor  controller  to  drive 
the  DC  motor  with  up  to  1 1  amps  of  continuous  current.  At  maximum  speed,  the  steering  mechanism  can 
be  moved  between  its  two  extreme  positions  in  2  seconds. 

Feedback  is  obtained  from  an  encoder  on  the  motor  shaft  that  is  mated  to  the  steering  wheel,  which  is 
always  turned  a  specified  amount.  Differences  between  intended  and  achieved  radius  occur  due  to 
linkage  non-linearities  and  factors  such  as  friction  between  the  road  and  the  wheels,  grade  of  the  road, 
vehicle  speed,  and  speed  with  which  the  steering  wheel  is  turned. 

Limit  switches  on  the  steering  linkage  are  hardwired  inputs  to  the  controller  board  and  provide  both  a 
safety  stop  to  protect  the  steering  mechanism  and  a  reference  point  for  roughly  calibrating  the  steering 
control  system  to  a  known  position  on  power-up  or  system  reset. 

2.4.3  Drive 

A  single  axis  motor  controller  services  the  drive  system.  The  voltage  (-10V  to  10V)  produced  by  the 
motor  controller  is  converted  to  a  current  signal  (-100mA  to  100mA)  by  an  amplifier  that  directly  operates 
a  hydraulic  servo  valve  to  set  the  speed  of  the  hydraulic  motor.  Acceleration  of  the  vehicle  is  limited  by  a 
ramp/hold  circuit,  mentioned  in  Section  2.4.1 ,  in  effect  providing  a  low  pass  filter  to  the  input  signal  An 
optical  300-line  incremental  encoder  mounted  on  the  hydraulic  motor  shaft  provides  feedback  to  the 
motor  controller.  Because  the  transmission  is  downstream  of  the  hydraulic  motor  (i.e  ,  between  the  motor 
and  the  driveshaft),  the  encoder  pulses  must  be  interpreted  differently  for  high  and  low  gears 


2.5  Sensors/Oevices 

At  present,  the  controller  features  for  handling  sensors  are  not  fully  implemented.  Two  fronts  of 
expansion  are  proposed  for  the  near  future.  An  Inertial  Navigation  System  will  be  incorporated  to  provide 
continuous  position  and  orientation  information.  A  Bitbus  network  will  be  used  to  monitor  and  control 
devices  distributed  around  the  vehicle. 

2.5.1  Inertial  Navigation 

An  Inertial  Navigation  System  (INS)  to  be  deployed  on  the  NavLab  will  receive  distance  data  as  input  and 
will  provide  position  and  inclination  data  along  the  axes  specified  as  output.  The  INS  detects  initial 
heading  on  its  own  and  provides  updates  of  position  and  heading. 

The  following  information  will  be  obtained  from  the  INS: 

1 .  True  heading  of  the  vehicle  --  0.5  degree  resolution. 

2.  Rate  of  change  of  heading  --  0.5  degs/sec  resolution. 

3.  X,  Y,  2  position  in  cm  -- 10  cm  resolution.  This  will  allow  movement  on  a  100  km2  grid. 

4.  Roll  and  pitch  inclination  --  0.5  degree  resolution. 

Performance  criteria  include: 

•  Dead  Reckoning  Capability:  Speeds  along  the  direction  of  travel  of  up  to  60  km/hour;  turning 
speeds  (change  of  orientation)  of  up  to  40  degrees/sec. 

•  Accuracy:  Maximum  long  track  error:  1%  of  distance  traveled.  Maximum  cross  track  error: 

0.1  degree/hour. 

•  Updates:  Must  be  able  to  handle  the  accuracy  requirements  above  with  updates  coming  only 
once  an  hour  or  once  in  5km. 

•  Necessity  of  Stopping:  Must  not  need  more  than  5  minutes  for  the  vehicle  to  be  completely 
stationary  on  power-up  or  on  recalibration. 

At  present  a  device  that  uses  three  mechanical  gyroscopes  and  requires  an  odometer  input  is  being 
considered.  A  second  device  being  considered  is  a  strap-down  system  that  uses  ring  laser  gyroscopes. 
This  is  much  more  accurate  than  the  first  and  does  not  require  odometer  input. 

2.5.2  Sensors/Devices  on  Bltbus  Network 

The  following  is  a  list  of  sensors  and  devices  that  are  monitored  and  controlled  by  the  Bitbus  network. 
Scan  cycle  time  indicates  the  period  at  which  each  of  the  sensors  is  monitored.  Temperature  units  are 
degrees  centigrade.  Pressure  units  are  pounds/sq.  inch. 


Sensor 

Thermocouples 

Scan  Cycle 

Minimum 

Maximum 

Engine  Oil 

30  sec 

0  deg 

175  deg 

Engine  Coolant 

30  sec 

0  deg 

150  deg 

NavLab  Cabin 

30  sec 

-10  deg 

40  deg 

NavLab  External 

30  sec 

-10  deg 

40  deg 

Hydraulic  Reservoir 

30  sec 

0  degs 

100  degs 

Pressure  Transducers 

Engine  Oil 

10  sec 

0  psi 

60  psi 

Hi -pressure  System  (input) 

10  sec 

0  psi 

3000  psi 

Hi-pressure  System  (output) 

10  sec 

0  psi 

3000  psi 

Voltages  &  Currents 


Battery  Voltage 

30  sec 

o  v 

15  V 

RPM 

2  sec 

o  v 

5  V 

GAS  Level 

60  sec 

o  v 

5  V 

Low  Level  Reservoir 

60  sec 

o  v 

5  V 

Swash  Plate  Angle 

1  sec 

-10  V 

10  V 

Switch  Settings 

Transmission  Gear  State  1  sec 
Generators  (2)  1  sec 
Beat  Exchanger  1  sec 


3.  Vehicle  Shell 

NavLab’s  foundation  is  a  1985  General  Motors  Vandura  cutaway  chassis  chosen  as  a  commercial  base 
to  simplify  development.  As  acquired,  the  vehicle  consisted  of  a  chassis,  a  drivetrain  and  a  cab.  A 
custom  shell  was  constructed  to  house  the  onboard  AC  power  generation,  power  distribution,  control  and 
computing  equipment.  Space  for  operators  is  provided,  allowing  research  activity  within  the  confines  of 
the  vehicle.  The  original  configuration  also  included  a  350  ci  V-8,  cruise  control,  an  automatic 
transmission,  dual  rear  wheels,  power  steering,  power  brakes  and  a  33  gal  fuel  tank. 

3.1  Exterior  Design 

The  shell  was  custom-built  with  particular  attention  paid  to  strength  requirements,  anticipating  needs  for 
extensibility.  The  roof  and  cab  support  air-conditioning,  antennas,  sensors,  and  working  personnel.  The 
floor  of  the  shell  supports  about  2000  kg.  The  shell  is  dimensioned  so  that  researchers  can  stand  inside; 
five  equipment  racks  are  housed  side  by  side  along  one  side  of  the  vehicle.  Figure  3-1  shows  a  rear  and 
side  view  of  the  vehicle. 

The  shell  is  made  entirely  of  steel.  Heavy  gauge  was  used  on  the  front  and  back  walls  while  lighter 
gauges  were  used  along  the  side  walls  and  roof.  A  metallic  blue  paint  protects  the  entire  shell.  There  are 
compartments  for  the  generators  and  power-related  equipment.  Louvered  metal  doors  provide  outside 
access;  there  is  no  access  to  these  compartments  from  inside  the  vehicle  to  keep  fumes  from  entering  the 
shell. 

A  wiring  port  in  the  floor  behind  the  driver's  seat  allows  wiring  from  the  underside  to  enter  the  vehicle. 
Another  access  vent  in  the  shell  above  the  passenger  compartment  enables  wiring  from  cameras  and 
range  sensors  to  enter  the  vehicle. 

3.2  Interior  Design 

Figure  3-2  shows  a  topdown  view  of  the  NavLab.  The  cab  has  two  seats,  one  for  a  driver  and  one  for  a 
passenger.  A  console  located  between  the  two  seats  allows  the  operator  to  control  and  monitor  the 
transmission.  A  research  area  behind  the  cab  contains  computing,  sensing,  and  control  equipment,  as 
well  as  space  for  two  researchers. 

Five  equipment  racks  are  located  on  the  left  side.  A  desk  area  extending  the  length  of  the  research  area 
is  located  opposite  the  racks  across  the  aisle.  Three  video  monitors  mounted  above  the  desk  area  can 
swivel  to  a  desired  viewing  position. 

Along  the  rear  edge  of  the  desktop  an  outlet  strip  provides  power  for  the  various  terminals  and  test 
equipment.  Bott-down  inserts  with  elastic  straps  prevent  computer  equipment  from  sliding  on  the  desktop 
when  the  vehicle  is  moving. 

Cabling  between  devices  passes  through  cable  trays  mounted  close  to  the  ceiling.  The  tray  design 
securely  holds  video  and  communication  cables  but  allows  for  easy  removal  or  addition.  Track-mounted 
lights  above  the  desk  area  provide  independently  aimed  illumination. 

In  addition  to  the  two  seats  in  the  cab,  a  swivel  seat,  centered  in  the  desk  area,  is  mounted  on  the  wall  of 
a  generator  compartment.  Extra  removable  seats  can  be  mounted  in  the  aisle  for  more  researchers. 


Fiber  insulation  between  the  shell  and  interior  panels  also  provides  protection  from  the  heat.  Insulation 
inside  and  outside  the  shell  helps  control  interior  climate.  Underfloor  insulation  keeps  heat  from  the 
hydrostats  and  exhaust  from  entering  the  interior.  Flat  sheets  of  liberglass  covered  with  thin  gauge 
aluminum  are  inserted  in  floor  areas  between  frame  members.  High  temperature  silicon-based  insulation 
covered  with  heavy  gauge  aluminum  foil  covers  exhaust  pipes. 


4.  Locomotion 

Steering  and  drive  motions  coordinate  to  drive  the  NavLab  through  planned  trajectories.  Both  axes  of 
motion  are  controlled  by  analog  signals  issued  by  the  controller  while  in  automatic  mode  or  through 
manual  controls. 


4.1  Steering 

Figure  4-1  shows  a  front  and  side  view  of  the  NavLab  steering  mechanism. 


Figure  4-1 :  Steering  Adaptation 

The  original  linkage  and  steering  column  are  driven  by  a  DC  servomotor  mounted  below  the  steering 
column.  The  motor  is  connected  to  the  steering  column  shaft  via  a  precision  toothed  belt;  two  toothed 
pulleys  provide  a  gear  reduction  of  5  to  1.  This  configuration  provides  high  enough  torque  to  turn  the 
steering  shaft  but  low  enough  for  the  operator  to  overpower  the  steering  motor  in  an  emergency.  A 
special  hub  ties  all  the  steering  elements  together  and  a  safety  enclosure  houses  the  moving  parts.  Limit 
switches  at  the  extremes  of  steering  travel  prevent  command  error  from  damaging  the  system. 

4.2  Drive 

A  hydraulic  pump  and  motor  combination  comprises  NavLab  drive.  This  hydrostatic  combination  was 
selected  because  it  provides  precise  control  of  position,  speed  and  acceleration.  Hydrostatic  equipment 
also  has  a  long  history  of  smooth  control  and  finely  adjustable  response. 

Drive  power  comes  from  the  main  vehicle  engine.  Engine  RPM  is  limited  by  a  governor  to  prevent 
overdriving  the  attached  hydraulic  pump.  Pump  output  is  controlled  by  an  analog  signal.1  The 

’This  signal  originates  from  either  a  foot  pedal  that  replaces  the  standard  gas  pedal  or  a  drive  controller,  depending  on  whether 
the  vehide  is  in  manual  or  automatic  mode 
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Figure  4-2:  Schematic  of  Vehicle  Drivetrain 

displacement  of  the  pump  (proportional  to  the  signal  from  the  footpedal)  determines  the  speed  at  which 
the  hydraulic  motor  moves.  The  motor  in  turn  powers  a  two-speed  transmission  which  operates  at  either 
a  4:1  (low  gear)  or  1 :1  (high  gear)  ratio,  turning  the  driveshaft  connected  to  the  vehicle  differential.  Figure 
4-2  shows  a  schematic  of  the  drivetrain. 

The  configuration  described  above  makes  control  of  vehicle  motion  simpler  than  if  the  vehicle 
transmission  and  brakes  had  to  be  controlled  to  produce  desired  velocity.  The  standard  braking  system  is 
intact  but  is  only  used  in  case  of  emergency  because  the  analog  signal  to  the  hydraulic  pump  controls 
both  accelerations  and  decelerations. 

4.2.1  Vehicle  Engine 

The  standard  350  ci  V-8  engine  is  the  main  source  of  driving  power.  The  following  modifications  were 
made: 

•  An  electrically  actuated  clutch  was  installed  to  couple  the  vehicle  engine  to  the  hydraulic 
pump.  The  clutch  is  disengaged  to  isolate  it  from  the  engine  when  the  engine  is  being 
started. 

•  The  alternator  was  upgraded  to  a  120  amp  dual  output  unit  to  satisfy  the  additional 
requirements  of  the  two-battery,  12  volt  system  onboard. 

•  One  stock  emission  control  air  pump  was  substituted  by  a  hydraulic  power  takeoff  unit.  It  is 
driven  from  the  crankshaft  end  and  shares  a  stock  V-belt  with  the  power  steering  pump. 


•  An  engine  oil  cooler  was  installed  to  reduce  oil  deterioration  caused  by  the  constant  high 
engine  temperature. 


4.2.1 .1  Engine  RPM  Control 

An  engine  RPM  control  keeps  the  vehicle  engine  running  at  a  determined  range  of  RPM  irrespective  of 
grade  and  speed.  A  magnetic  pickup  on  the  output  shaft  of  the  engine  provides  feedback  to  a  specialized 
controller  that  maintains  a  constant  RPM  by  moving  an  actuator  linked  to  the  engine  carturetor.  Figure 
4-2  shows  a  schematic  of  the  mechanism. 
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Figure  4-3:  Mechanism  for  Engine  RPM  Control 

4.2.2  Hydraulic  Pump 

The  output  of  the  engine  drives  a  hydraulic  pump  through  a  flexible  coupling.  The  pump  is  suspended 
from  a  frame  crossmember  with  rubber  shock  mounts  to  allow  movement  with  the  engine. 

The  pump,  a  Sunstrand  axial  piston  pump,  is  equipped  with  an  electronic  displacement  control  valve  that 
alters  the  angle  of  an  internal  swashplate  between  0  and  18  degrees,  depending  on  an  input  signal  that 
varies  from  -10  to  10  V.  Negative  voltages  cause  the  pump  to  turn  in  the  reverse  direction.  At  0  volts  the 
pump  has  a  holding  torque  to  keep  the  vehicle  stationary.  At  10  V  the  displacement  is  maximum, 
corresponding  to  maximum  driving  speed. 

Hydraulic  fluid  is  supplied  to  the  pump  from  the  reservoir  by  an  integral  charge  pump  to  replace  the  fluid 
pumped  to  the  motor  while  an  equal  amount  of  surplus  hot  oil  is  drained  from  the  pump  case  and  passed 
through  the  main  heat  exchanger. 

4.2.3  Hydraulic  Motor 

Hydraulic  power  from  the  pump  is  transmitted  to  a  matching  fixed  displacement  motor  attached  directly  to 
the  transmission.  High-pressure  flexible  hose  couples  the  motor  and  pump.  Because  the  motor  is  a  fixed 
displacement  type,  it  always  turns  the  same  amount  for  every  unit  volume  of  fluid  pumped  in,  resulting  in 
an  RPM  of  the  motor  that  is  directly  proportional  to  the  input  signal  of  the  pump. 

A  10  micron  filter  cleans  the  return  leg  of  the  high  pressure  system.  An  additional  crossmember  supports 
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Figure  4-4:  Hydro  Drive  System 
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the  hydrostatic  motor.  The  motor  unit  has  an  SAE  standard  shaft  mounted  to  a  mating  flange  on  the 
driveshaft's  forward  universal  joint  yoke. 

4.2.4  Transmission 

The  Funk  transmission,  an  electrically  shifted  two-speed  gear  box  installed  between  the  hydraulic  motor 
and  the  driveshaft,  is  bolted  to  a  reinforced  frame  member.  It  is  mechanically  coupled  to  the  motor  on  the 
input  side  and  to  the  driveshaft  on  the  output  side.  The  transmission  provides  a  ratio  of  3.950:1  in  low 
gear  and  1.0441:1  in  high  gear.  Low  gear  supports  low-speed  experimentation  (0-20  km/h);  high  gear 
(0-40  km/h)  transports  the  vehicle  along  public  roads  in  manual  mode.  The  gear  is  selected  electronically 
by  applying  a  voltage  to  one  of  two  solenoids  on  the  transmission;  if  neither  solenoid  is  activated,  the 
transmission  is  in  neutral  gear.  It  is  necessary  to  shift  into  neutral  when  changing  from  one  gear  to 
another. 

A  flow-through  lubrication  and  charge  system  was  added  to  the  transmission  to  circulate  hydraulic  fluid. 
The  fluid  is  returned  to  the  reservoir  through  a  low-pressure  filter. 

4.2.5  Reservoir,  Heat  Exchanger,  and  Filters 

A  reservoir  holds  about  80  liters  of  hydraulic  fluid.  Because  seals  and  bearing  surfaces  are  sensitive  to 
temperature  and  contamination  of  the  hydraulic  fluid,  oil  returned  to  the  reservoir  must  be  allowed  enough 
time  to  de-aerate  and  cool.  Heat  is  removed  by  passing  oil  from  the  pump  case  drain  through  a  heat 
exchanger.  Cooled  oil  is  directed  back  to  the  reservoir.  Dirt  in  the  oil  is  filtered  at  two  points:  in  the  return 
leg  of  the  high-pressure  system  and  between  the  transmission  and  the  reservoir. 

A  series  of  valves  assist  in  the  cooling  and  circulation  of  working  fluid.  A  shuttle  valve  and  a  low  pressure 
bleed-off  valve  act  together  to  allow  a  small  portion  of  the  working  fluid  to  circulate  through  the  oil  cooler 
and  reservoir.  A  make-up  pump  replenishes  the  fluid  that  is  removed  via  a  bleed-off  valve. 

The  reservoir  is  equipped  with  a  thermistor  and  a  level  gauge  to  relay  tank  status  to  the  vehicle  controller. 

4.2.6  Hydrostat  Sensor  and  Control  System 

Figure  4-5  shows  the  sensing  and  control  system  associated  with  the  hydraulic  drive  system.  All  the 
components  are  located  on  the  underside  of  the  vehicle  so  all  lines  enter  the  vehicle  through  a  wiring  port 
in  the  floor  behind  the  driver’s  seat. 

Control  lines  include: 

1 .  Hydrostatic  pump  displacement:  This  line  controls  the  swash  plate  angle  in  the  pump 
regulating  the  displacement  of  hydraulic  fluid  to  the  motor. 

2.  Gear  selection:  This  line  controls  the  gear  (high  or  low)  of  the  transmission. 

3.  Heat  exchanger  fan  control:  This  line  controls  the  on/off  state  of  a  fan  that  cools  the 
hydraulic  fluid. 

Sensors  include: 

1 .  Dirty  filter  sensors:  one  dirty  filter  sensor  is  installed  in  each  of  the  high-  and  low-pressure 
legs  of  the  hydraulic  system.  These  sensors  trigger  an  alarm  when  they  become  clogged. 

2.  Pressure  transducers:  These  read  system  pressure  at  input  and  output  of  the  hydraulic 
motor. 
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Figure  4-5:  Hydrostat  Sensor  and  Control  Lines 
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3.  Reservoir  sensors:  These  measure  fluid  level  and  temperature  of  hydraulic  fluid  in  the 
reservoir. 

4.  Motor  encoder  feedback:  An  optical  encoder  mounted  on  the  shaft  of  the  hydraulic  motor 
provides  feedback  to  the  drive  controller. 

5.  Steering  limit  switches:  Limit  switches  are  installed  on  the  steering  mechanism  to  signal  an 
alarm  if  the  wheels  are  cranked  beyond  acceptable  limits. 


5.  Electrical  System 

All  the  electrical  power  needed  by  the  NavLab  is  available  onboard  the  vehicle.  Electrical  power  can, 
however,  be  brought  in  from  a  shore  power  plug  while  the  vehicle  is  in  a  fixed  location.  Power  is 
distributed  such  that  the  generators  are  not  needed  to  drive  the  NavLab  manually. 

5.1  AC  Power 
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5.1.2  Shore  Power 

The  NavLab  can  plug  into  power  from  a  building  when  stationary,  alleviating  constant  generator 
operation.  An  extension  cord  from  a  nearby  power  outlet  (220  VAC  50A)  mates  to  a  220  VAC  single¬ 
phase  plug  mounted  in  the  outside  center  compartment. 

5.1.3  Power  Conditioning 

Because  variations  in  load  and  temperature  affect  generator  power  output,  the  power  from  the  generators 
must  be  be  conditioned  to  protect  sensitive  machinery  from  spikes  and  brown-outs.  This  is  done  by 
passing  power  through  Uninterruptable  Power  Supplies  (UPS).  These  devices  not  only  condition  the 
power  from  the  generators  but  also  provide  full-load  backup  for  up  to  15  minutes,  even  if  the  generators 
or  shore  power  are  shut  down,  allowing  a  graceful  system  shutdown  if  power  fails.  Three  UPS  devices 
provide  a  total  of  6KW  of  conditioned  power,  which  will  more  than  suffice  for  a  complete  configuration  of 
computing  equipment.  The  lights,  air  conditioner,  video  monitors,  and  servo-amplifiers  do  not  receive 
conditioned  power  because  they  are  much  less  prone  to  fluctuations  in  generator  output. 

5.2  DC  Power 

Because  many  of  the  devices  onboard  use  DC  power,  the  standard  vehicle  12  V  system  was  extended  by 
adding  an  extra  battery  and  replacing  the  alternator  with  a  dual  output  120  amp  unit  that  charges  both 
batteries. 

Figure  5-2  shows  a  wiring  schematic  for  the  DC  power  system.  The  original  battery  powers: 

1 .  Vehicle  ignition  -  starting  power  for  the  engine; 

2.  Dash  panel  -  all  switches  on  the  dash  panel; 

3.  Interior  lights  -  overhead  lights  in  the  research  area; 

4.  Control  electronics  --  the  input  voltage  to  two  power  supplies.  One  converts  the  12  V  into 
-12  V  and  the  other  converts  12  V  to  5  V.  Each  power  supply  has  a  limit  of  3  amps. 

The  second  battery  provides: 

1 .  starting  power  for  the  generators; 

2.  power  for  generator  compartment  lights; 

3.  power  to  run  the  hydraulic  fluid  cooler  fan. 

An  additional  28V  power  supply  is  mounted  in  the  equipment  racks.  This  takes  an  input  from  the  1 10  AC 
system  and  produces  up  to  30  amps  of  current,  most  of  which  is  used  by  an  ERIM  laser  scanner.  The 
inertial  navigation  device  will  operate  on  the  same  power  supply. 
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6.  Telemetry 

Telemetry  to  the  vehicle  was  thought  to  be  useful  where  environmental  sensitivity,  location,  or  size  ot 
computing  equipment  precludes  installation  onboard  the  NavLab.  This  feature  has  not  yet  found  use  in 
practice.  NavLab  telemetry  provides  control  and  monitoring  from  a  remote  site,  allowing  stationary 
computers  to  be  used  in  navigation  experiments. 


Figure  6-1 :  Telemetry  Configuration  of  NavLab 

The  scenario  in  Figure  6-1  shows  the  closed  loop  set-up  of  a  vehicle  experiment  where  computing  might 
be  distributed  offboard.  The  camera  outputs  a  video  signal  that  is  broadcast  over  a  UHF  frequency  and 
picked  up  by  an  antenna  and  receiver  located  on  the  Carnegie  Mellon  campus.  The  receiver  provides  the 
video  signal  to  a  frame  buffer  within  the  computer  that  processes  the  image.  The  signal  is  digitized  and 
then  analyzed.  Commands  to  the  vehicle  are  sent  over  a  serial  line  to  a  wireless  modem.  A  radio 
modem  on  the  vehicle  picks  up  this  signal  and  feeds  it  to  the  controller. 

6.1  High  Bandwidth  Transmission 

An  experimental  radio  license  obtained  from  the  FCC  covers  several  broadcast  frequencies.  The  license 
covers  2  UHF  television  channels,  a  full  duplex  radio  link,  and  a  2  MHz  microwave  link. 

The  video  signal  is  transmitted  on  the  video  transmitter  while  range  data  are  transmitted  over  an  aural 
sideband  of  one  UHF  channel.  Because  transmission  rates  can  be  as  high  as  56  K  baud,  the  other  aural 
sidebands  not  currently  in  use  could  serve  several  other  data  transmission  needs. 

6.2  Low  Bandwidth  Transmission 

Two  sets  of  1200  baud  radio  modems  are  used  for  simple,  low-bandwidth  digital  communication.  These 
devices  provide  a  transparent  RS-232  connection  between  computers  and  facilitate  sending  commands 
to  and  from  an  offboard  machine  and  the  NavLab  controller. 


6.3  Cellular  Phone 

Separation  of  vehicle  from  stationary  base  facilities  involves  not  only  communication  over  distance  for  the 
machines  but  also  for  humans.  For  this  reason,  a  cellular  phone  using  existing  mobile  communications 
networks  within  the  city  has  been  installed. 


7.  Perceptive  Sensing  and  Computing 

A  variety  o<  sensors  can  be  mounted  on  the  NavLab  depending  on  the  type  ot  research  being  conducted. 
Vision,  laser  ranging,  and  sonar  ranging  are  the  most  popular  sensing  modes.  More  details  of  sensors 
and  computing  can  be  found  in  articles  listed  in  Appendix  V. 

7.1  Video 

Cameras  provide  a  standard  RS-170  video  image  to  the  frame  buffer.  Vision  processing  transforms  this 
image  into  a  scene  description  to  support  navigation. 

Typically,  a  single  camera  mounted  in  the  front  of  the  vehicle  provides  a  wide-angle  view  of  the  scene. 
Some  vision  algorithms,  however,  call  for  a  stereo  pair  of  cameras.  Broadcast-quality  cameras  that 
provide  red-green-blue  color  signals  are  used.  Remote  control  units  allow  control  over  camera  functions 
like  gain,  color  balance,  and  iris  size.  Presently,  camera  focus  and  zoom  must  be  controlled  manually. 

7.2  Laser  Ranging 

Laser  ranging  is  useful  in  areas  where  vision  algorithms  fail  -  in  detecting  depth  discontinuities  in  scenes 
where  the  edges  are  not  obvious  and  in  those  scenes  that  have  uneven  lighting  because  of  shadows. 
Whereas  the  camera  is  a  passive  instrument,  the  laser  rangefinder  is  an  active  device  that  emits  a  beam 
in  a  raster  fashion  and  captures  the  reflection  to  provide  two  types  of  information  -  distance  and 
reflectance.  The  data  are  then  analyzed  to  provide  a  scene  description.  Laser  ranging  provides  a  direct 
3-D  description  of  the  scene  while  vision  requires  more  expensive  computation  to  extract  this  information. 
Range  readings  are  particularly  useful  because  they  are  not  affected  by  ambient  light. 

The  current  laser  ranging  device,  manufactured  by  ERIM,  provides  a  256x64x8  bit  depth  map.  The 
scanner  output  is  processed  by  a  Motorola  M68000  processor  and  sent  to  a  Sun  computer  dedicated  to 
ranging. 

7.3  Pan  and  Tilt  Mechanism 

Vision  and  ranging  sensors  can  be  mounted  in  various  configurations.  Most  configurations  call  for  two 
independent  pan  motions  -  one  for  the  laser  scanner  and  another  for  the  cameras.  Tilt  is  needed  for 
both  the  laser  scanner  and  cameras. 

Pan  and  tilt  design  reflects  a  need  to  accurately  position  sensors  over  a  large  viewing  range.  Less  than  4 
seconds  is  required  to  view  180  degrees. 

Cameras  are  mounted  on  rigid  5  cm  diameter  aluminum  poles  2  meters  long  mounted  horizontally 
through  a  worm  drive  gearset  with  a  hollow  bore.  The  gearset  provides  a  50:1  ratio  and  is  driven  by  a  DC 
brushed  servo  motor.  An  800  line  encoder  provides  feedback  for  the  tilt  motion. 

7.4  Computing  Configuration  for  Sensing 

Figure  7-2  shows  configuration  of  computing  for  simple,  perceptive  sensing.  Much  more  complex  setups 
are  common.  Each  sensor  commonly  requires  its  own  workstation  or  specialized  processor.  Another 
computer  runs  the  blackboard  system  that  integrates  perception,  modeling,  and  planning. 


Figure  7-1 :  Pan  and  Tilt  Mechanism 
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Figure  7-2:  Typical  Architecture 
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I.  Modifications  to  Vehicle 

The  chassis  was  originally  rated  for  10.000  tbs.  gross  vehicle  weight.  The  final  vehicle  weight  was 
established  as  12,000  lbs.,  thus  necessitating  a  more  robust  suspension.  In  order  to  achieve  the 
necessary  load  rating  the  front  coil  springs  were  upgraded  and  two  extra  leaves  were  added  to  the  rear 
springs,  increasing  the  gross  vehicle  weight  by  2400  lbs.  Heavy  duty  gasoil  shock  absorbers  were 
installed  to  minimize  a  slight  tendency  to  pitch  due  to  the  extra  weight.  In  addition,  the  original  equipment 
tires  were  exchanged  for  Goodyear  radiais  with  a  higher  load  and  all-weather  rating. 

Modifications  to  the  frame  were  minimized  to  preserve  strength  and  stiffness.  However,  in  order  to  mount 
some  of  the  larger  hydrostatic  components  alterations  had  to  be  made.  The  main  forward  crossbeam, 
transmission  rear  support  beam  and  surrounding  floor  were  completely  removed.  The  crossbeam  was 
replaced  by  a  box  section  which  bridges  the  hydrostatic  pump.  A  channel  section  was  added  as  support 
for  the  pump  and  also  provides  additional  frame  strength. 


II.  Power  Budget 

NavLab  AC  power  requirements  have  risen  steadily  since  the  first  integration  to  accommodate  the  WARP 
computing  system,  air  conditioning,  and  unintermiptible  power  supplies  (UPS).  Power  is  currently 
provided  by  a  20.0  kW  generator.  The  power  budget  is  as  follows: 


CIRCUIT  PEAR 

AMP  DRAH 

PEAK  WATTAGE 

FUSE 

Main  No .  1 

90 

10, 000 

100 

Coleman  Air  Conditioner 

17.5 

1,930 

20 

Lights  (4  /  100  w) 

3.6 

400 

5 

Monitor  Strip  (5  /  80  w) 

3.6 

400 

5 

PMI  Amplifier 

18.2 

2,000 

20 

Desk  Strip  (10  /  60  w) 

5.5 

600 

10 

Sola  UPS  (600  w  output) 

7.0 

750 

10 

Intel  Controller  Computer 

11.4 

1,250 

* 

Behlman  UPS  (2000  w  output) 

27.0 

3,  000 

40 

Sun  Vision  Host  Computer 

12.0 

1,320 

* 

Disk  Drives 

6.3 

700 

* 

Development  Circuit 

15.0 

1,  650 

20 

Main  No.  2 

90 

10,000 

100 

McLean  Midwest  Air  Conditioner 

14.0 

1,540 

20 

Behlman  UPS  (2000  w  output) 

27.0 

3,000 

40 

Sun  HARP  Host  Confute r 

12.0 

1,320 

* 

Disk  Drives 

6.3 

700 

* 

VME  HARP  Control  Cage 

9.0 

1,000 

* 

Behlman  UPS  (2000  w  output) 

27.0 

3,000 

40 

HARP  Power 

16.4 

1,  800 

* 

Video 

4.5 

500 

5 

Erim  Laser  Scanner 

2.7 

300 

5 

Development  Circuit 

15.0 

1,  650 

20 

38 


III.  Weight  and  Center  of  Gravity  Budget 

Location  in  { x,y )  is  given  with  left  (driver’s  side)  rear  comer  as  the  origin.  Positive  y  is  toward  the  cab, 
positive  x  toward  the  passenger  side.  The  shell  is  241  cm  wide  (x)  and  343cm  long  (y). 


Item: 


Location  (cm, cm) 


Weight 


Driver 

63,368 

79.4 

Passenger 

152,368 

79.4 

Empty  Rack  £  10kg 
hardware 

51,  34 

81.6 

51,103 

81.6 

51,171 

81.6 

51,240 

81.6 

51,309 

81.6 

Signal  Wiring 
Power  Wiring 
Insulation 


22.7 

45.4 

13.6 


Passenger  aide 


Generator 

203,  58 

117.9 

203,285 

117.9 

Air  Conditioner 

117,200 

52.2 

Power  Conditioner 

224,171 

100.7 

Breaker  Panel 

201,  8 

18.1 

Table  Top 

201,171 

31.8 

Monitor  Shelf 

216,170 

2.3 

Sony  Monitors 

208,279 

14.1 

208,165 

14.1 

Seat 

132,157 

18.1 

Operator 

Terminals 

132,157 

68.0 

Sun 

201,216 

27.2 

wyae 

Marlite 

201,102 

6.8 

back  wall 

122,  0 

9.5 

left 

0,171 

26.3 

right 

241,171 

11.8 

front 

122,343 

5.0 

Gas  Tank 

135,  97 

119.7 

Shore  Power  Switch 

198,135 

18.1 

198,183 

18.1 

Shore  Power  Plug 

198,152 

2.3 

Track  Lights 

185,178 

4.5 

Hydraulic  Equipment: 

Funk 

109, 

,287 

Reservoir 

201, 

272 

Sunstrand  Pump 

122, 

373 

Sunatrand  Motor 

89, 

330 

Pall  Filter 

51, 

333 

Dowty  Tandem  Pump  £ 

Charge  Pump  Motor 

135, 

203 

Heat  Exchanger  £  Fan 

53, 

51 

124.7 

136.0 

132.9 

74.4 

11.3 

5.9 

24.9 


39 


Rack  1 : 

UPS 

2  Amplifiers, 

1  Transformer, 

3  Power  Supplies 
Intel  Chassis 
Patch  Panel  6 

Control  Circuitry 
Tables 

Total  42,287 


Rack  2 : 

Video 

ERXM  Power  Supply 
Total  42,226 

Rack  3 : 

Sun 

UPS 

Total  42,165 

Rack  4 : 

Sun 

Total  42,104 

Rack  5 : 

Empty 

Total  42,  43 


Pan  6  Tilt 

2  1135  Motors 
2  Turntables 
1  Tilt  Gearing 

1  Aluminum  Rod 

2  JVC's 
ERXM 

PMX  motor 
56  C  Coupling 
Bracketing 


54.4 


52.2 
24.9 

9.1 

11.3 
152.0 


22.7 
24.0 

46.7 


68.0 

54.4 

122.5 


68.0 

68.0 


0.0 


8.9 

26.3 

22.7 

4.5 

5.0 

34.0 

4.5 

4.5 


Total 
Shell 
Van  Bodv 


lower  mount 
upper  mount 


121,447 

121,171 


front  axle 
rear  axle 


101,427 

101,109 


Overall: 

Center  of  Gravity:  112,244 


Weight  Total:  5449kg 


18.1 

45.4 

174.0 


1153 


1120 

649 


IV.  Implementation  of  the  Virtual  Vehicle  Instruction  Set 
Protocol 

A  simple  high-level  handshaking  protocol  has  been  designed  for  RS-232  communication  between  the 
Virtual  Vehicle  and  any  host  computer  issuing  commands  to  the  vehicle.  It  provides  a  means  of 
exchanging  commands  and  status  information  with  a  reasonable  level  of  reliability  and  optional  error 
recovery.  The  motivation  for  this  is  that  errors  in  communication  should  be  detected  and  acted  upon 
without  interfering  with  normal  operations  of  host  or  Virtual  Vehicle.  By  adhering  more  or  less  strictly  to 
the  protocol,  the  relative  importance  and  subsequent  computational  overhead  of  error-free  communication 
can  be  chosen  at  will  and  may  be  varied  dynamically. 

Messages  between  Virtual  Vehicle  and  host  are  of  the  following  form: 

clengthXpacket  IDXopcode>  [<argument  1>/  .  . /<argument  n>/]<CR> 

The  individual  fields  of  a  packet  are  defined  as  follows: 

<iength>  2  characters  wide.  Contains  the  total  number  of  ASCII  characters  in  the  packet, 

including  the  length  field  itself.  Length  is  represented  in  decimal,  so  messages  are 
limited  to  99  characters. 

<packet  id>  3  characters  wide.  Unique  identifier  to  be  used  as  reference  to  the  packet  in 
subsequent  protocol  transactions.  Can  be  any  combination  of  printable  ASCII 
characters  (20H  -  7FH),  although  numeric  values  (30H  through  39H)  will  be  used 
most  frequently.  See  description  below  for  usage  and  purpose  of  this  field. 

<opcode>  2  characters  wide.  Represents,  in  decimal,  the  numeric  index  of  the  command  to  be 

acted  upon  by  the  Virtual  Vehicle.  This  implies  a  range  of  0  through  99  tor  possible 
opcodes. 

<arguments>  Zero  or  more  numeric  arguments,  of  variable  width.  Arguments  are  terminated  by  a 
slash  (T).  Leading  zeroes  are  allowed.  All  arguments  must  be  integer  values. 

<cr>  Carriage  Return  (ODH)  character  indicates  end-of-packet.  Must  follow  immediately 

after  the  last  argument-terminating  slash,  or  after  the  opcode  in  the  case  of  zero 
arguments.  The  <cr>  is  NOT  considered  part  of  the  packet,  so  it  is  not  included  in 
the  <length>  field. 

The  following  rules  define  the  handshake  between  two  devices.  They  should  be  followed  closely  to 
achieve  maximum  communication  reliability.  However,  as  is  indicated  in  the  appropriate  paragraphs, 
error  checking  is  done  at  the  discretion  of  the  receiving  device. 

•  For  every  packet  to  be  sent,  the  sending  device  generates  a  unique  3-character  packet  ID 
code.  This  can  be  done,  for  example,  by  incrementally  numbering  packets  or  by  encoding  the 
current  system  time.  Random  generation  of  codes  is  discouraged,  since  this  theoretically 
allows  duplicate  packet  ID’s.  Using  the  full  range  of  96  symbols  in  each  of  the  3  character 
positions  yields  a  range  of  884,736  unique  ID  codes,  which  is  in  excess  of  the  anticipated 
number  of  messages  exchanged  during  a  typical  mission  of  the  Virtual  Vehicle. 

•  Packets  are  prefixed  with  the  length  of  the  packet  and  terminated  by  the  end-of-packet 
character  <CR>.  The  receiving  device  should  check  the  actual  length  of  the  received  packet 
against  the  <iength>  field  to  ensure  integrity  of  each  packet. 

•  Each  packet  received  may  be  further  validated  by  ensuring  that 

•  the  opcode  is  valid, 

•  the  number  of  arguments  is  correct  for  the  given  opcode,  and 

•  the  arguments  are  within  allowable  limits.  These  limits  may  change  dynamically  as  a 


function  of,  for  example,  vehicle  speed  or  road  conditions. 

•  If  none  of  the  above  error  conditions  are  detected,  the  receiving  device  returns  an  ACK 
message  to  the  sender,  indicating  that  the  message  was  received  correctly  and  the 
appropriate  action,  if  any,  is  being  performed.  The  ACK  message  uses  the  same  packet  ID 
as  that  of  the  message  being  acknowledged. 

•  In  case  of  an  error,  the  receiving  device  must  return  a  NAK  message  to  the  sender  to 
indicate  that  the  packet  was  rejected  and  no  command  is  being  executed.  As  its  only 
argument,  the  NAK  message  contains  an  error  code  indicating  the  reason  for  rejecting  the 
packet.  A  NAK  message  also  has  the  same  packet  ID  code  as  the  message  in  question. 

•  Upon  receiving  a  NAK  as  reply  to  a  message,  a  device  has  the  option  of  retransmitting  the 
offending  message  (with  new  packet  ID),  logging  the  error,  ignoring  it,  or  taking  any  other 
action  that  might  be  appropriate.  By  the  same  token,  while  expecting  a  NAK  or  ACK  in 
response  to  a  transmitted  message,  a  device  may  choose  to  time  out,  wait  forever,  or  take 
other  appropriate  action.  These  conventions  provide  for  very  flexible  operation  that  allows 
critical  system  operations  to  continue  even  in  case  of  protocol  errors.  In  dealing  with  these 
situations,  the  Virtual  Vehicle  will  adhere  to  the  following  conventions: 

•  NAK  or  ACK  messages  are  always  generated  and  sent  in  response  to  data  messages 
received  by  the  Wl.  At  this  point,  handshake  for  the  current  message  is  considered 
complete:  i.e.,  no  further  action  is  expected. 

•  Unexpected  NAK  or  ACK  messages  (i.e.,  those  referring  to  an  unknown  or  previously 
acknowledged  packet  ID)  are  ignored.  However,  the  error  is  logged  and/or  announced 
at  the  W  system  console. 

•  If  a  NAK  is  received  as  response  to  a  message  originated  by  the  W,  the  message 
may  or  may  not  be  retransmitted  repeatedly  (with  a  new  packet  ID),  depending  on  the 
type  of  message  and  reason  for  rejection. 

•  If  neither  NAK  nor  ACK  is  received  by  the  W  within  a  certain  timeout  period 
(configurable  parameter,  typically  on  the  order  of  seconds),  the  error  condition  is 
logged  and/or  announced  at  the  W  system  console.  After  this,  the  W  still  expects  a 
response  to  the  packet  in  question,  but  no  further  action  is  taken  and  subsequent 
messages  are  treated  as  if  no  error  had  occurred. 

Commands  issued  by  Host/Console 

Mnemonic  Opcode  Meaning  Arguments 


NAK 


ACK 

ABO 

STO 


00 


01 

02 

03 


Negative  Acknowledge  cc/ 

cc=  00  :  Packet  length  error 
01  :  Num.  of  Args  error 
02  :  Not  ready  for  cmd 
03  :  Illegal  Opcode 
IX  :  X'th  argument  below 

current  minimum  limit 
(1  <  X  <  9) 

2X  =  X'th  argument  above 

current  maximum  limit 
(1  <  X  <  9) 

Acknowledge 
Abort  Motion 
Stop/Suspend  Motion 
Startup 


[• 


CHP 

06 

Change  Position 

x/y/h/ 

x  :  A  x  pos. 
y  :  A  y  pos. 
h  :  A  heading 

STM 

11 

Set  time  to  zero 

SVL 

12 

Set  Velocity 

v/i/ 

v  :  velocity 
i:ls  immediate 

SAC 

13 

Set  Acceleration 

a/i/ 

a  :  acceleration 
i  :  1  s  immediate 

SP1 

14 

Set  Pan  1 

P/ 

p  :  pan  angle 

ST1 

15 

Set  Tilt  1 

t/ 

t  :  tilt  angle 

SP2 

16 

Set  Pan  2 

P/ 

p  :  pan  angle 

ST1 

17 

Set  Tilt  2 

t/ 

t  :  tilt  angle 

SSR 

18 

Set  Steering  Rate 

s/ 

s  :  steering  rate 

{0-99  %) 

INP 

21 

Get  Vehicle  Info 

POS 

22 

Get  position 

TIM 

23 

Get  Vehicle  Time 

VEL 

24 

Get  Vehicle  Velocity 

ACC 

25 

Get  Vehicle  Acc. 

PHI 

26 

Get  Pan  Angle  1 

TL1 

27 

Get  Tilt  Angle  1 

PN2 

28 

Get  Pan  Angle  2 

TL1 

29 

Get  Tilt  Angle  2 

STR 

30 

Get  Steering  Rate 

ROL 

31 

Get  Roll 

RLR 

32 

Get  Roll  Rate 

PIT 

33 

Get  Pitch 

PTR 

34 

Get  Pitch  Rate 

HDR 

35 

Get  Beading  Rate 

REP 

36 

Get  Status 

d/ 

d  :  device  number 

Responses  from  Virtual  Vehicle 

Mnemonic 

Opcode 

Meaning 

Arguments 

NAK 

00 

Negative  Acknowledge 

cc/ 

cc=  00  :  Packet  length  error 

01  :  Num.  of  Args  error 
02  :  Hot  ready  for  cmd 

03  :  Illegal  Opcode 

IX  :  X'th  argument  below 

current  mini mum  limit 
(1  <  X  <  9) 


2X  =  X'th  argument  above 

current  maximum  limit 
(1  <  X  <  9) 


ACX 

RV1 


01 

51 


Acknowledge 
Vehicle  Info 


1/w/h/g/m/x/y/s/ 


43 


o 

$ 


33 


i 


$ 


Vehicle  position 


t/y/h/t/ 


length 

width 

height 

weight 

minimum  turning  radius 
X  of  C.G 
Y  of  C.G 
0  ~  wheel  steer 
1  =  skid  steer 


z  position 
y  position 
heading 
time 


RVT 

53 

Vehicle  Time 

t/ 

KW 

54 

Vehicle  Vel. 

v/t/ 

RVA 

55 

Vehicle  Acc. 

a/t/ 

RP1 

56 

Pan  angle  1 

p/t/ 

RT1 

57 

Tilt  Angle  1 

t/t/ 

RP2 

58 

Pan  angle  2 

p/t/ 

RT2 

59 

Tilt  Angle  2 

t/t/ 

RSR 

60 

Steering  Rate 

a/t/ 

RRL 

61 

Roll 

r/t/ 

RRR 

62 

Roll  Rate 

r/t/ 

RPT 

63 

Pitch 

p/t/ 

RPR 

64 

Pitch  Rate 

p/t/ 

RHR 

65 

Heading  Rate 

h/t/ 

RST 

66 

Report  Status 

d/s/t/ 

d 

ADN 

80 

Arcdone 

s 

id/x/y 

status  code 


id  :  arc  ID  coda 
x,y  :  Pos.  at  end  of  arc 
h  :  heading  at  end  of  arc 
t  :  time  at  end  of  arc 


Note:  All  distance  units  are  cm,  time  units  are  msecs,  velocity  units  are  cm/s,  acceleration  units  are  cm/s2 
and  angle  units  are  half  degrees.  Weight  units  are  kilograms. 


V.  References 

Goto,  Y.  and  A.  Stentz.  The  CMU  System  for  Mobile  Robot  Navigation,"  in  IEEE  International 
Conference  on  Robotics  and  Automation,  1 987. 

Hebert,  M.  and  T  Kanade.  "Outdoor  Scene  Analysis  Using  Range  Data,"  in  IEEE  International 
Conference  on  Robotics  and  Automation,  1986. 

Kanade,  T.,  C.  Thorpe,  and  W.  Whittaker.  "Autonomous  Land  Vehicle  Project  at  CMU,"  in  ACM 
Computer  Conference,  February  1986. 

Kanade,  T.  and  C.  Thorpe.  CMU  Strategic  Computing  Vision  Project  Report:  1984  -  1985,  Technical 
Report,  The  Robotics  Institute,  Carnegie  Mellon  University,  1985. 

Krogh,  B.  and  C.  Thorpe.  "Integrated  Path  Planning  and  Dynamic  Steering  Control  for  Autonomous 
Vehicles,"  in  IEEE  International  Conference  on  Robotics  and  Automation,  1986. 

Shafer,  S.,  A  Stentz,  and  C.  Thorpe.  "An  Architecture  for  Sensor  Fusion  in  a  Mobile  Robot,"  in  IEEE 
International  Conference  on  Robotics  and  Automation,  1986. 

Thorpe,  C.  1986  Year  End  Report  for  Road  Following  at  Carnegie  Mellon,  Technical  Report,  The  Robotics 
Institute,  Carnegie  Mellon  University,  1986. 

Wallace,  R.,  A.  Stentz,  C.  Thorpe,  C.  Moravec,  W.  Whittaker,  and  T.  Kanade.  "First  Results  in  Robot 
Road-Following,"  in  International  Joint  Conference  on  Artificial  Intelligence,  1985. 

Wallace,  R.,  K.  Matsuzaki,  Y.  Goto,  J.  Crisman,  J.  Webb,  and  T.  Kanade.  "Progress  in  Robot  Road- 
Following,"  in  IEEE  International  Conference  on  Robotics  and  Automation,  1986. 


